home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-piscitello-ftp-bigports-01.txt < prev    next >
Encoding:
Text File  |  1993-06-16  |  8.7 KB  |  329 lines
  1. IETF                               Page 1
  2. June 2, 1993     FTP Operation Over Big Address    Internet Draft
  3.  
  4.  
  5.          FTP Operation Over Big Address Records (FOOBAR)
  6.  
  7.  
  8.                  David M. Piscitello
  9.                            Bellcore
  10.                   dave@sabre.bellcore.com
  11.  
  12.  
  13.                        Status of this Memo
  14.  
  15. This document is an Internet Draft.  Internet Drafts are working
  16. documents of the Internet Engineering Task Force (IETF), its
  17. Areas, and its Working Groups. Note that other groups may also
  18. distribute working documents as Internet Drafts.
  19.  
  20. Internet Drafts are draft documents valid for a maximum of six
  21. months. Internet Drafts may be updated, replaced, or obsoleted by
  22. other documents at any time.  It is not appropriate to use
  23. Internet Drafts as reference material or to cite them other than
  24. as a "working draft" or "work in progress."
  25.  
  26. Please check the Internet Draft abstract listing contained in the
  27. IETF Shadow Directories (cd internet-drafts) to learn the current
  28. status of this or any other Internet Draft.
  29.  
  30.  
  31.                           Introduction
  32.  
  33. This Internet-Draft specifies a method for assigning long
  34. addresses in the HOST-PORT specification for the data port to be
  35. used in establishing a data connection for File Transfer
  36. Protocol, FTP (RFC959, 1985). This is a general solution,
  37. applicable for all "next generation" IP alternatives, and can
  38. also be extended to allow FTP operation over transport interfaces
  39. other than TCP.
  40.  
  41.  
  42.                             Abstract
  43.  
  44. This paper describes a convention for specifying longer addresses
  45. in the PORT command.
  46.  
  47.  
  48.                          Acknowledgments
  49.  
  50. Many thanks to all the folks in the IETF who casually mentioned
  51. how to do this, but who left it to me to write the internet
  52. draft. Special thanks to Rich Colella, Bob Ullmann, Shawn
  53. Ostermann, Steve Lunt, and Brian Carpenter who had the time and
  54. decency to comment on the initial draft:-)
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67. IETF                               Page 2
  68. Internet Draft               FOOBAR                  June 2, 1993
  69.  
  70.  
  71. 1.  Background
  72.  
  73. The PORT command of File Transfer Protocol allows users to
  74. specify an address other than the default data port for the
  75. transport connection over which data are transferred. The PORT
  76. command syntax is:
  77.  
  78. PORT <SP> <host-port> <CRLF>
  79.  
  80. The <host-port> argument is the concatenation of a 32-bit
  81. internet <host-address> and a 16-bit TCP <port-address>.  This
  82. address information is broken into 8-bit fields and the value of
  83. each field is transmitted as a decimal number (in character
  84. string representation).  The fields are separated by commas.  A
  85. port command is thus of the general form "PORT
  86. h1,h2,h3,h4,p1,p2", where h1 is the high order 8 bits of the
  87. internet host address.
  88.  
  89. To accommodate larger network addresses anticipated for all IP
  90. "next generation" alternatives, new commands and reply codes are
  91. needed for FTP. This memo addresses these needs.
  92.  
  93.  
  94. 2.  The LPORT Command
  95.  
  96. The LPORT command allows users to specify a "long" address for
  97. the transport connection over which data are transferred. The
  98. LPORT command syntax is:
  99.  
  100.             LPORT <SP> <long-host-port> <CRLF>
  101.  
  102. The <long-host-port> argument is the concatenation of the
  103. following fields;
  104.  
  105.    o+ an 8-bit <address-family> argument (af)
  106.  
  107.    o+ an 8-bit <host-address-length> argument (hal)
  108.  
  109.    o+ a <host-address> of <host-address-length> (h1, h2, ...)
  110.  
  111.    o+ an 8-bit <port-address-length> (pal)
  112.  
  113.    o+ a <port-address> of <port-address-length> (p1, p2, ...)
  114.  
  115. The <address-family> argument takes the value of the protocol
  116. number of the "next generation" IP address (see Assigned Numbers,
  117. RFCxxxx, 1993), or generally speaking, a network layer protocol.
  118. Relevant assigned IPng version numbers are:
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133. IETF                               Page 3
  134. June 2, 1993     FTP Operation Over Big Address    Internet Draft
  135.  
  136.  
  137.      Decimal         Keyword
  138.      ------          -------
  139.      0               reserved
  140.      1-3             unassigned
  141.      4               Internet Protocol (IP)
  142.      5               ST Datagram Mode
  143.      6               SIP
  144.      7               IX (from TP/IX)
  145.      8               PIP
  146.      9               TUBA/CLNP
  147.      10-14           unassigned
  148.      15              reserved
  149.  
  150. The value of each field is broken into 8-bit fields and the value
  151. of each field is transmitted as an unsigned decimal number (in
  152. character string representation, note that negative numbers are
  153. explicitly not permitted).  The fields are separated by commas.
  154.  
  155. A LPORT command is thus of the general form
  156.  
  157. LPORT af,hal,h1,h2,h3,h4...,pal,p1,p2...
  158.  
  159. where h1 is the high order 8 bits of the internet host address,
  160. and p1 is the high order 8 bits of the port number (transport
  161. address).
  162.  
  163. [Note: Brian Carpenter of Cern has observed that this
  164. representation is counter-intuitive for cases where the natural
  165. representation of part of an OSI network service access point
  166. address is binary coded decimal (BCD); for example, those with
  167. E.164 International numbers for ISDN included. Readers are
  168. encouraged to post comments if this is inappropriate.]
  169.  
  170.  
  171. 3.  The LPASV Command
  172.  
  173. The L(ONG) PASSIVE command requests the server-DTP to listen on a
  174. data port other than its default data port and to wait for a
  175. connection rather than initiate one upon receipt of a transfer
  176. command.  The response to this command includes the address
  177. family, host address length indicator, host address, port address
  178. length, and port address this server is listening on.  The reply
  179. code and text for entering the passive mode using a long address
  180. is 228 (Interpretation according to FTP is: positive completion
  181. reply 2yz, connections x2z, passive mode entered using long
  182. address xy8).  The suggested textual message to accompany this
  183. reply code is:
  184.  
  185. 228 Entering Long Passive Mode (af,hal,h1,h2,h3,h4...,pal,p1,p2...)
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198. IETF                               Page 4
  199. Internet Draft               FOOBAR                  June 2, 1993
  200.  
  201.  
  202. 4.  Permanent Negative Completion Reply Codes
  203.  
  204. The negative completion reply codes that are associated with
  205. syntax errors in the PORT and PASV commands are appropriate for
  206. the LPORT and LPASV commands (500, 501). An additional negative
  207. completion reply code is needed to distinguish the case where a
  208. host supports the LPORT or LPASV command, but does not support
  209. the address family specified. Of the FTP function groupings
  210. currently defined for reply codes (syntax, information,
  211. connections, authentication and accounting, and file system),
  212. "connections" seems the most logical choice; thus, an additional
  213. negative command completion reply code, 521 is added, with the
  214. following suggested textual message:
  215.  
  216. 521 Address family <af> not supported
  217.  
  218. Where <af> is the value of the protocol number of the "next
  219. generation" IP address noted earlier.
  220.  
  221.  
  222. 5.  Rationale
  223.  
  224. An explicit address family argument in the LPORT command and PASV
  225. reply allows the Internet community to experiment with a variety
  226. of "next generation IP" alternatives within a common FTP
  227. implementation framework. (It also allows the use of a different
  228. address family on the command and data connections.) An explicit
  229. length indicator for the host address is necessary because some
  230. of the IPNG alternatives make use of variable length addresses.
  231. An explicit host address is necessary because FTP says it's
  232. necessary.
  233.  
  234. The decision to provide a length indicator for the port number is
  235. not as obvious, and certainly goes beyond the necessary condition
  236. of having to support TCP port numbers. Currently, at least one
  237. IPng alternative (TP/IX) supports longer port addresses. And
  238. given the increasingly "multi-protocol" nature of the Internet,
  239. it seems reasonable that someone, somewhere, might wish to
  240. operate FTP operate over Appletalk, IPX, and OSI networks as well
  241. as TCP/IP networks. (In theory, FTP should operate over *any*
  242. transport protocol that offers the same service as TCP.) Since
  243. some of these transport protocols may offer transport selectors
  244. or port numbers that exceed 16 bits, a length indicator may be
  245. desirable. If FTP must indeed be changed to accommodate larger
  246. network addresses, it may be prudent to determine at this time
  247. whether the same flexibility is useful or necessary with respect
  248. to transport addresses.
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264. IETF                               Page 5
  265. June 2, 1993     FTP Operation Over Big Address    Internet Draft
  266.  
  267.  
  268. 6.  Conclusions
  269.  
  270. The mechanism defined here is simple, extensible, and meets both
  271. IPNG and possibly multi-protocol internet needs.
  272.  
  273.  
  274. 7.  References
  275.  
  276. RFC959          Postel, J., and Reynolds, J., "File Transfer Protocol"
  277.                 October 1985.
  278.  
  279. RFCxxxx         Reynolds, J., and Postel, J., "Assigned Numbers", <date>
  280.                 (probably does not include recently assigned IPv7 numbers).
  281.  
  282. RFC1123         Braden, R.,ed. "Requirements for Internet hosts -
  283.                 application and support", 1989 October.
  284.  
  285.  
  286. 8.  Author Information
  287.  
  288. David M. Piscitello
  289. Bell Communications Research
  290. NVC 1C322
  291. 331 Newman Springs Road
  292. Red Bank, NJ 07701
  293. dave@mail.bellcore.com
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.